Markup languages are used to describe data by including tags that distinguish information about the data from the data itself. A client process (“client”) executing on one node of the network employs network protocols to send a request message in the markup language to a server process (“server”) executing on another node. The server responds to the request by providing a service and often employs the network protocols to return a response message in the markup language to the client. The messages are addressed to the proper process on the proper node based on a system for naming the processes on the network. For example, the Universal Resource Identifier (URI) names the node (domain) where a process executes and a directory where a particular executable file resides on that domain.
Extensible Markup Language (XML) provides a common syntax for expressing structure in data. Structured data refers to data that is tagged for its content, meaning, or use. XML provides an expansion of the tagging that is done in Hypertext Markup Language (HTML) and the related Structured Generalized Markup Language (SGML), which focus on format or presentation. In XML the meaning (semantics) of the data can be provided as well as the presentation format. Many applications employ proprietary implementations of XML to communicate between a server and a client. Simple Object Access Protocol (SOAP) is a proposed implementation of XML for exchanging data objects between two processes or “communicating parties” that are independently developed, as described in Simple Object Access Protocol 1—1.htm on the Web at domain and directory w3.org/TR/SOAP, hereinafter referenced as SOAP1.1.
A SOAP message is an XML document that includes a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. There is a fairly strong similarity between these SOAP elements and the elements of a letter in a postal service. The SOAP envelope, as with a letter's envelope, serves as the unit of transport. The SOAP body, like a letter's contents, is to be carried without being examined or changed. And the SOAP header, like the outside surface of a letter's envelope, is available for various marks or annotations that can affect transport and delivery without disturbing the contents. The invention is related to the use of these markers in the SOAP header
The names and attributes of the standard SOAP message elements are defined by an XML schema stored on domain schemas.xmlsoap.org in directory /soap/envelope. The SOAP envelope is the top level XML element of the schema; it is named “Envelope.” The optional SOAP header is an optional child element of Envelope and is named “Header.” The SOAP body is a mandatory child element of Envelope and is named “Body.” The data objects sent between the communicating parties are included in the SOAP Body.
For example, assume that a user purchases and installs a personal stock portfolio (PSP) application to run on the user's computer. The user also registers with a stock quotation service provided by Company XYZ over the Internet. Company XYZ executes a stock quotation (SQ) application, which retrieves data from the stock markets and answers requests for data from one or more PSP applications. The PSP application on the user's computer communicates with the SQ application on the Company XYZ computer using Internet protocols. Inside the packets transported over the Internet are SOAP messages for passing data objects that describe stock prices between the PSP application and the SQ application. The stock price object type is described and values for one or more stock price objects, which are instances of the stock price object type, are included in a SOAP body of the SOAP message. The PSP and SQ applications are the client and server communicating parties, respectively, in this example.
The PSP application sends a SOAP message to the SQ application that includes a list of stock ID objects in the SOAP Body. Each stock ID object is an instance of a stock ID type. In response, the SQ determines the prices of those stocks identified by the stock ID objects and sends a SOAP message to the PSP application that includes a list of stock price objects in the SOAP Body.
SOAP allows each of the independently developed communicating parties to change under continued development. The Header element of a SOAP message includes one or more child elements called header entries. Each header entry has a name and corresponds to an extension of the contents or meaning of the data in the SOAP message beyond the contents or meaning originally established for the communicating parties. Each header entry element includes two attributes, an actor attribute and a mustUnderstand attribute. The actor attribute identifies the recipient for whom the extension is intended, identified by the recipient's URI.
The mustUnderstand attribute is set to “1” to indicate that the recipient must be configured to process the extension corresponding to the header entry. The mustUnderstand attribute is set to a different value if the recipient can ignore the extension. If a recipient receives a SOAP message with an extension having a mustUnderstand value of “1” and the recipient is not configured for that extension, the recipient must respond with an error message. That is, an application that does not modify the use of data in the SOAP message based on a header entry with a mustUnderstand attribute of “1” must return an error to the application that sent the SOAP message. This provides a flexible mechanism for extending a message in a decentralized and modular way, without prior knowledge between the communicating parties.
For example, assume that the user upgrades from a PSPversion1 application to a PSPversion2 application obtained from Company ABC. The PSPversion2 application includes, in the SOAP Body of the SOAP message sent to a SQ application, a list of stock price objects instead of a list of stock ID objects. Each stock price object includes a stock ID object that identifies the stock. Each stock price object also includes the price obtained the last time the PSP application requested the price for that stock. The PSPversion2 application is designed to work with a revised SQ application, SQversion2, which automatically sends additional information for stocks (“threshold stocks”) that have changed more than a threshold amount since the last time the PSP application requested stock prices.
To indicate this change to the SOAP message transmitted to the SQ application, a header entry is added to the Header element of the SOAP message. For example, the header entry is named “Threshold” and the mustUnderstand attribute of the header entry is set to “1.” An SQ application that does not modify the use of data in the SOAP message based on the header entry “Threshold” will not perform properly. For example, such an SQ application would not be expected to retrieve the stock ID from a stock price object in the SOAP request instead of from a stock ID object in the SOAP request. Such an application must return to the PSPversion2 application a SOAP error message indicating that the SQ application cannot process the request in the SOAP message. On receiving the mustUnderstand error, the PSPversion2 application can fall back to sending a message that would be sent by the PSPversion1 application to the SQversion1 application.
These problems also may arise in the specific context of network hardware and software that performs application-switching or content-switching functions, such as with content switching products formerly commercially available from Arrowpoint and now commercially available from Cisco Systems, Inc., San Jose, Calif.
Based on the foregoing, there is a clear need for techniques for masking version differences in applications that use a data object exchange protocol.
In particular, there is a need for techniques for masking mustUnderstand errors arising in applications that exchange data objects using SOAP.
There is also a specific need for techniques for masking mustUnderstand errors arising in applications that are switched by a content services switch or equivalent device.